Skip to content

Conversation

arturcic
Copy link
Member

@arturcic arturcic commented Oct 8, 2025

Follow up for #4681

@HHobeck
Copy link
Contributor

HHobeck commented Oct 8, 2025

@pvanbuijtene: Thank you for your contribution and the work you have done.

I have following remarks/suggestions:

  • The classes Commit, Branch and so on are wrapper classes around the LibGit2Sharp objects. I would say the wrapper classes should not have a reference to GitRepostory. Is it an idea to extract the functionality of caching in a separate class and use this instead?
  • Because of the nature of a wrapper class I would expect that the LibGit2Sharp objects are reused as well and the hash code is the same (otherwise we would have still a memory problem). Probably you can use the hash code instead of using an arbitrary string (needs to be tested).

@arturcic
Copy link
Member Author

arturcic commented Oct 8, 2025

@pvanbuijtene: Thank you for your contribution and the work you have done.

I have following remarks/suggestions:

  • The classes Commit, Branch and so on are wrapper classes around the LibGit2Sharp objects. I would say the wrapper classes should not have a reference to GitRepostory. Is it an idea to extract the functionality of caching in a separate class and use this instead?
  • Because of the nature of a wrapper class I would expect that the LibGit2Sharp objects are reused as well and the hash code is the same (otherwise we would have still a memory problem). Probably you can use the hash code instead of using an arbitrary string (needs to be tested).

That was my idea to move the functionality from the GitCache class back into the GitRepository as I think the repository wrapper should handle the caching mechanism as it's the abstraction of the database which maintains the collections and the cache, but we can reconsider that

@pvanbuijtene
Copy link

Happy to help :)

@arturcic as I understand you will implement the suggestions, feel free to ping me in case you want to have some changes tested against a repository causing issues.

@arturcic
Copy link
Member Author

arturcic commented Oct 8, 2025

@pvanbuijtene thank you, yeah, I implemented the suggestions so far in this PR, but it's a draft for now, I want to test caching the other collections as well before having this merged

@arturcic arturcic force-pushed the fix/cache-git-objects branch 6 times, most recently from 7393ace to ec03709 Compare October 13, 2025 22:46
@arturcic arturcic changed the title improves git object cache Improves git object cache Oct 14, 2025
@arturcic arturcic force-pushed the fix/cache-git-objects branch 2 times, most recently from e78fba2 to 468ac8d Compare October 14, 2025 06:05
Simplifies branch/tag cache keys by including the remote name and SHA.
Renames `GetOrCreate` to `GetOrWrap` to better reflect its caching behavior.
refactors the project to improve code organization and maintainability.
Replaces several internal classes with readonly structs to improve performance by avoiding unnecessary heap allocations. Updates related code to ensure compatibility with the new struct-based implementation.
moves schema and testing projects to misc folder.
Uses lazy initialization to cache references and remotes.
Introduces `GitRepositoryCache` to centralize caching logic for branches, commits, tags, references, and remotes. Updates related classes to use `GitRepositoryCache` instead of directly maintaining individual cache dictionaries.
Replaces `Refs` with `References` across the codebase for better clarity and consistency. Updates all method calls, variable names, and interfaces to reflect this change.
Replaces direct instantiations of Tags, Commits, Remotes, and References with lazy initialization. This avoids redundant object creation and improves performance by deferring instantiation until the collection is accessed.
@arturcic arturcic force-pushed the fix/cache-git-objects branch from 468ac8d to ac0e28b Compare October 15, 2025 15:52
Copy link

@arturcic
Copy link
Member Author

@pvanbuijtene do you have the time to test this PR on the big repository you have and compare?

@pvanbuijtene
Copy link

@arturcic sure, the changes seem to have introduced some additional memory usage:

main: peak around 380MB
image

this pr: peak around 725MB
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants